HTTP/1.1 Upgrade header

HTTP
Persistence · Compression · HTTPS
Request methods
OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT
Header fields
Cookie · ETag · Location · Referer
DNT · X-Forwarded-For
Status codes
301 Moved permanently
302 Found
303 See Other
403 Forbidden
404 Not Found

HTTP/1.1 introduced support for the Upgrade header field. In the exchange, the client begins by making a clear-text request, which is later upgraded to a newer http protocol version or switched to a different protocol. Connection upgrade must be requested by the client, if the server wants to enforce an upgrade it may send a "426 upgrade required" response. The client can then send a new request with the appropriate upgrade headers.

Contents

Use with TLS

One use is to begin a request on the normal http port but switch to Transport Layer Security (TLS).[1] In practice such use is rare with the https URL scheme being a far more common way to initiate encrypted http.

The server returns a 426 status-code to alert legacy clients that the failure was client-related (400 level codes indicate a client failure: List of HTTP status codes).

This method for establishing a secure connection is advantageous because it:

A disadvantage of this method is that the client cannot specify the requirement for a secure HTTP in the URI. Therefore a man-in-the-middle may maintain an unencrypted and unathenticated connection with the client while maintaining an encrypted connection with the server.

Use with websockets

WebSocket also uses this mechanism to set up a WebSocket connection with a HTTP server in a compatible way.

See also

References

  1. ^ RFC 2817